Remade the pull request with only the intended commit.

Do let me know if I can provide anything to help get this merged. Happy to update docs for it if you find the features useful.

Thanks again for this contribution, and I’m sorry this PR also went without a decision for so long.

I understand the appeal of invoking a parameterized method as a simple button using its default values. It is a useful idea, but I’m concerned that adding another invocation mode to [Button] would increase the complexity of both the API and its behavior.

Where possible, I would prefer to solve this using Alchemy’s existing building blocks. For example, optional inputs can be represented as non-serialized Inspector fields while the button method itself remains parameterless:

[NonSerialized, ShowInInspector]
[LabelText("Specify Number of Foos")]
bool specifyNumberOfFoos;

[NonSerialized, ShowInInspector]
[ShowIf(nameof(specifyNumberOfFoos))]
[LabelText("Number of Foos")]
int numberOfFoos;

[Button]
[LabelText("More Method")]
void MoreMethod()
{
    var value = specifyNumberOfFoos ? numberOfFoos : 50;
    Debug.Log($"FooAmount: {value}");
}

Although this requires a little more code, it makes the behavior explicit and allows existing attributes such as [LabelText], [ShowIf], and grouping or validation attributes to be applied independently to each input. I think that flexibility is more valuable than adding a special parameter-hiding mode to [Button].

I can also see the convenience of generating a readable label with ObjectNames.NicifyVariableName. However, Alchemy is intended to support everyone working in Unity projects, not only programmers. For artists and designers, the internal method name and signature are implementation details rather than useful UI information. An explicitly chosen label through [LabelText] communicates the purpose of the action more clearly and gives the component author control over what users see.

The remaining improvement - initializing parameter fields from their declared default values is useful, but equivalent behavior has since been implemented on the current main branch, so I’m going to close this PR as part of the current maintenance cleanup.

Thanks again for taking the time to propose and implement these improvements.